低代码缺少的五大组件

【CSDN 编者按】前段时间有个很有趣的话题，说程序员太难了，前有 AI 自动编程掀餐桌，后有 6 岁小孩抢饭碗。低代码让没有任何技术背景的普通人也能参与到编程中来，这无疑是对程序员行业的一个冲击！但是，低代码真的可以取代程序员的地位么？它就没有缺点么？……

译者 | 弯月    责编 | 张文

出品 | CSDN（ID：CSDNnews）

低代码开发平台（Low Code Development Plat，LCDP）是无需编写代码或通过少量代码就可以快速生成应用程序的开发平台。由于采用了可视化的编程方式，因此开发人员无需掌握专业的编程技术。

低代码开发平台的一个显著的特点是，任何人都可以参与应用程序开发，无需任何技术背景。对于大型企业来讲，低代码开发平台还可以降低 IT 团队培训、技术部署的初始成本。然而，低代码开发平台也有着其自身无法避免的局限性。

本文总结了当前各大低代码开发平台缺少的、但对开发人员极其重要的五大组件。

基于云的开发环境

通常，软件开发人员通过本地的开发环境构建软件，然后再存储到基于云的 git 代码库中，比如 GitHub 等。在编写脚本的时候，我们通常会使用虚拟环境构建，包括代码、复杂的文件目录结构以及第三方依赖项。问题在于，为了将这些本地命令行的脚本转换为生产工具，我们还需要很多基本的工具，比如配置服务器、部署源代码、配置文件等。

此外，还需要考虑到健壮性，比如 CI/CD、单元测试等。大量此类的基础设施工作所需的时间，往往超过了核心的应用程序。因此，我们需要一个基于云的开发环境，我可以把它当成本地的主机，但是我的脚本可以无缝地转换成生产软件。

然而，许多低代码或无代码开发平台的核心都是 JSON 解析实用程序。用户可以通过这些平台提取 JSON 数据（通过第三方 API），然后解析键值对，再传递给另一个 API 或接口。比如，从JSON数据中读取某个邮件地址，然后调用邮件发送服务 API。

虽然这类的 JSON 解析服务非常方便，而且可以构建非常强大的自动化/接口。但是，围绕 JSON 解析构建的核心产品架构限制了可以通过低代码增强的应用程序类型。

为了解决这类问题，我们可以考虑将虚拟环境文件系统作为低代码开发平台的架构，可以读取、写入和删除任意的文件结构。在准备投入生产时，通过专用云服务上的核心平台引擎执行应用程序。事件触发器中的 JSON 数据可以作为导入变量传递到脚本中。

此外，这个虚拟文件系统可以支持各种编程语言和现成的依赖项。虚拟环境是基于云的，并且可以作为跨各种设备和操作系统的统一运行时环境。即使在本地桌面系统做开发，环境也可以在云中运行，但是感觉与本地计算机没有区别。最后，该虚拟环境还可以与第三方文件结构（例如 GitHub、S3、Dropbox 等）进行交互。在云服务器上运行的生产配置文件可以由该平台自动构建（而且还可以根据自定义的需求进行编辑），因此这个系统可以实现无缝衔接。

以方便编程为主，避免仅提供拖放式编程

在提到低代码时，大多数人都会想到可视化编程。尽管可视化编程也是一种低代码开发，但实际上软件开发的一切都是“低代码”，即通过高级的界面对低级代码进行抽象。例如，我们可以说 Python 编程语言是C语言的低代码抽象。换句话说，API 与可视化编程接口一样，都是低代码产品。这里的重点是，低代码和可视化编程之间应该有区别。

这种区别引发了两个问题。

• 首先，可视化编程是生产级脚本和工具的正确范例吗？
• 其次，这些平台最有价值的功能是什么？

对于第一个问题，答案是可视化编程可以为软件开发提供帮助，但也有可能成为一种障碍。关于有帮助性的可视化界面，举一个例子，设置定时作业，以执行脚本或与简单的 API 交互。可视化编程最常见的用途，就是通过软件组件提供简单而又通用的功能，但是其背后有大量专门的代码支持。然而，强制整个平台都使用可视化编程，则最终会陷入困境。代码是最简单、最快速的表达想法的方法。例如，使用可视化程序构建布尔逻辑（例如 if/else 语句）很快就会变得一团混乱。作为开发人员，我更加愿意使用 Python 编写逻辑。

可视化开发平台最有价值的功能是什么？

• 首先，最大的优势在于基于事件的内置触发机制（例如，当有新客户添加到数据库或 CRM 时）。通常，我们需要通过另一个系统（设置 Webhooks托管服务器）才能设置这类的触发系统。
• 其次，这些平台无需任何开发流程即可在云中无缝运行已构建的自动化功能。

因此，我们可以通过一个具有集成事件的虚拟环境平台，在应用程序执行时将请求响应数据推送到脚本中。其次，通过 API 处理认证/凭证，处理输入参数，并执行正确的查询，这样就可以节省很多时间。而这些 API 也可以利用可视化界面的优势（发送自定义电子邮件和消息等）。

文件依赖性管理

我们希望服务能够理解依赖关系，并将依赖关系作为有待解决的头等问题，例如，如果内部工具依赖于目录中的某个文件、特定的数据库模式或其他常量，则平台应该识别重大的变化，并立即通知利益相关者变化的内容。为了保证用户体验，我们应该允许用户无需大费周折即可轻松地构建单元测试。

与团队一起构建内部脚本和自动化工作流时，我们经常发现共享文件是生产稳定性潜在的痛点和弱点。例如，我们与一家公司合作，在 Google 表格上运行自动化的工作流程，但该表格同时由多名员工进行编辑。如果每个表格、列或特定单元格不小心被编辑了，则自动化就会出问题，而且没有任何提示（至少不会立即显示）。为了找出根本原因，我们需要耗费大量时间进行调试，而且还没有办法防止这种问题再次发生。再举一个例子，一家公司拥有一些内部工具，这些工具需要特定格式的数据库架构，而且在升级数据库时这些工具都会崩溃。现实情况是，文件依赖性和数据都很混乱，而许多平台都把管理这种混乱的任务交给了用户。

为了解决这个问题，低代码开发平台应该为每个程序自动生成配置文件，而且其中应该包含所有文件与文件夹的映射。这些文件的引用都应存储在元数据中。换句话说，应用程序“了解”文件的依赖关系以及依赖的性质（目录位置、内部数据结构、类型等）。在这种体系结构下，我们可以看到低代码之间的映射关系，即正在运行的脚本和工具系统中所有文件的相互依赖性。

版本集成

我们希望提供一种平台范式，让用户在云虚拟环境中无缝运行代码、脚本和服务器，同时又不需要开发运维或设置。与存储在第三方服务数据库中的专有程序相比，版本控制和协作更加容易应用到文件体系结构。换句话说，用户拥有源代码而不是服务。

然而，许多面向最终用户的的低代码/无代码开发平台的架构设计都是将程序代码保存在公司的数据库中。这种范式与大多数开发人员构建工具时使用的git代码库相反。git 范例的优势在于版本控制、可共享性、可移植性和协作（比如开源代码库）。对于构建工具而言，将所有元素都视为目录中的文件，方便开发人员存储程序以及协作开发，这一点至关重要。低代码程序的核心应该像系统中的可编辑文件一样，平台的目的是帮助用户完成配置（无论是通过可视化编程还是编写出色的文档）。这种范例可以帮助我们开发更复杂的工具，而且还可以利用开发人员已经在使用的许多工具（比如 GitHub）来控制源代码。此外，还有一个好处，这种体系结构可以解锁更多模块化的开发体验，操作更多基本的构建块（换句话说，用户可以根据需要编辑/理解最低级的代码）。

我认为，平台 GitBook 在构建文档方面做得很好。GitBook 提供的可视化界面很适合构建动态文档，而且基础的文档都保存在每个用户的 GitHub 账号中。GitBook 利用 GitHub 来处理冲突管理，并为开发人员提供更好的底层功能。

低代码开发平台应该帮助用户或自动地构造源代码中的配置文件，在云服务（脚本、服务器/端点等）上运行任意代码。与脚本相关的所有文件均归用户，且由用户保存。所有服务存储都引用这些文件的存储位置（GitHub、S3、Dropbox 等）。

灵活地选择供应商

对开发人员来说，被强制锁定到某个供应商是一个很大的障碍。如果这家供应商倒闭或涨价，怎么办？如果突然需要某个功能或更多资源，但这家供应商没有提供，该怎么办？如果被某个供应商锁定，遇到这些情况就麻烦了。

在构建软件工具时，随着时间的流逝，许多工具都会变成重要的一份子。作为开发人员，从头构建工具的最大好处在于，我拥有完整的自主权。我可以决定使用哪个框架、在何处托管等。

如今，大多数可视化编程平台都会将用户锁定在他们的系统中，他们认为这种“粘性”是一种商业优势。例如，在许多情况下，使用 AirTable 极为方便，但在构建工具时，选择它会让我感到不安，主要是因为我没有访问基础关系数据库的能力。

平台应该将自己提供的服务的每个组件（例如事件触发、托管、凭据等）都视为存储库中的文件。通过这种范例，我可以编写所有的代码，而且还可以使用其他服务随时替换配置文件。有时，这种工作很乏味，但是我希望拥有选择权。其次，这种架构有助于鼓励大家提供一流的服务。

总结

低代码可以帮助开发人员快速构建生产工具，但是，低代码的“可视化编程”平台往往也会限制开发人员。如果平台能够解决本文中提到的这些问题，就能得到所有开发人员的支持。

参考链接：

https://orshanjesse.medium.com/5-things-low-code-is-missing-377221936a5d

点分享点收藏点点赞点在看